1. Field of the Invention
The present invention relates to the remote booting of target client computing devices (“clients”) where the software that makes the clients fully operational for an end-user is obtained through a computer communications network (“a network”). This software is obtained during the boot process through the client's network interface from server computing devices (“boot servers”) that are repositories of that software. In particular, the present invention relates to the situation where clients that are composed of different sets of hardware components are introduced onto the network. Each unique set of client hardware components may require a unique set of software (i.e. a unique “client software definition”) to be transferred from the boot server to the client in order to boot the client successfully. The present invention provides a means for automatically constructing such a client software definition when clients are introduced onto the network.
2. Description of the Related Art
A boot process on a client (or any computing device) is defined as a sequence of program instructions that begins automatically when the client is powered-on or reset and completes when an end-user software environment is operational on the client. The initial instructions that are executed in a boot process are fixed in the nonvolatile read-only memory (“ROM”) of the hardware of the client so that they are always available to the client, even if it was previously shut off. As the boot process progresses, program instructions are located on a source outside of the client's ROM and copied, or loaded, into the client's volatile memory, also referred to as dynamic or random access memory (“RAM”). These instructions in RAM, referred to as software, are lost whenever the client is shut off or reset and therefore must be restored from an outside source during the boot process.
Once this software has been loaded into RAM, client execution is transferred from ROM memory to this software in RAM. This software continues the boot process by iteratively locating and loading additional software into the client's RAM as required until the end-user software environment is complete and operational. Typically, this end-user software environment contains an operating system (“OS”) that does the general operation of the hardware of the client. This end-user software environment may also contain additional system programs to operate specialty hardware on the client and application programs that perform the end-user operations on the client as defined by the enterprise that owns the client.
Some clients are configured with ROM that contains instructions that direct the boot process to obtain software through the client's network interface. This is distinguished from the instructions contained in the ROM of “stand-alone” clients that direct the boot process to obtain the software to establish the end-user software environment only from nonvolatile media repositories contained in devices that are directly attached to the client, such as diskettes, hard disks, and CD-ROMs. A remote boot process allows end-user software environments to be created, located and maintained in a repository on a centrally located boot server. This represents a significant savings of administrative effort when compared with having to perform the same activities at each separate client location.
The instructions that direct the boot process to the network interface may be included in the client's Basic Input-Output System (“BIOS”) ROM that contains the initial instructions to be executed after the client is started or reset. The instructions that direct the boot process in the network interface may also be contained in a separate, or “option” ROM attached to the network interface. The client's BIOS ROM can be configured to transfer client execution to the option ROM after the initial boot instructions in the BIOS ROM have completed. This network interface and its option ROM may be integrated into the client's main system board (“motherboard”) or placed on a separate hardware communications adapter that is connected to the client's motherboard. Another alternative remote boot configuration is to have the BIOS ROM load and transfer execution to software in RAM that emulates the instructions of a remote boot option ROM. Such remote boot emulation software can be obtained from media of a local device, such as a diskette, and permits clients to be remote booted even when their network interface hardware cannot contain an option ROM for that purpose.
Once the remote boot instructions in the BIOS ROM, option ROM, or remote boot emulation software begin to execute, they must initialize the network interface hardware so that it can send and receive signals on the network to which it is attached. This is accomplished through a series of well-known directives to that hardware. Then, the remote boot instructions must initiate and support network protocols that permit the client to announce itself to potential boot servers on the network as a client that requires a remote boot. These network protocols must also permit the client and a boot server to determine each other's network addresses so that they can direct network communications to each other. Finally, these network protocols must assure the accurate delivery of software and other information through the network between the boot server and the client.
Two sets of network protocols have become widely used for remote booting of clients on networks today. One set is called Remote Program Load or Remote Initial Program Load (“RPL” or “RIPL”). This older set of network protocols is associated with Local Area Networks (“LANs”) and is primarily used when the boot servers and the remote boot clients are attached to the same LAN. Generally, this requires that the boot servers and the remote boot clients be physically located close to each other.
A RPL client initiates the network boot process by transmitting a special broadcast frame on the LAN that indicates the unique media access control (“MAC”) identifier of the client's network interface hardware as its source and indicates that the client requires a RPL boot. As a broadcast, this special frame contains a unique, well-known destination MAC identifier that indicates that any other computing device (“host”) attached to the LAN can receive the frame. This includes any hosts that are boot servers. This broadcast frame with its well-known destination MAC identifier frees the remote boot client from the “chicken and egg” problem of having to initially know the destination MAC identifier of a particular boot server to get the remote boot process started.
A boot server responds to the receipt of this broadcast frame by looking up the remote boot client's MAC identifier as a key to a record that describes the required software for the client. This record is contained in a file that lists the records of all potential remote boot clients that the boot server may service. This record indicates the name of a file on a loading device (for instance a hard disk) attached to the boot server that contains an initial network bootstrap program (an “initial NBP”) that is to operate on the client. The RPL map file record also contains other configuration data about the client to aid in remote booting the client. The file containing the initial NBP is loaded from the loading device and transmitted on the LAN to the client as a frame or series of frames that indicate the client's MAC address as the destination. The RPL process re-directs the loaded initial NBP file to the boot server's network interface for transmission to the client instead of writing it to the boot server's own RAM.
Once it is transferred to the client, this initial NBP becomes the first software loaded into the client's RAM. RPL also provides a means for running this initial NBP on the client. This initial NBP initializes and restarts the client's network interface. It also retains the MAC identifier of the boot server as a destination for possible later requests. The initial NBP may be a complete end-user software environment, or a program that requests other files from the boot server in order to assemble an end-user software environment on the client.
The other, newer set of network protocols are built upon the underlying Internet Protocol (IP) that forms the basis for the Internet and other Telecommunications Control Protocol/Internet Protocol (“TCP/IP”) wide area networks (“WANs”). As the name “wide area network” implies, this set of protocols permits boot servers and remote boot clients to be physically located far from each other.
An early protocol used for remote boot in IP networks is the “Bootstrap Protocol” (“BOOTP”). BOOTP generally requires that the boot server and the remote boot clients be located on the same IP address sub-network, and as such gives little additional capability over RPL. BOOTP also requires that each remote boot client be pre-listed in a table on the boot server and assigned a fixed IP address in order to permit it to be booted. The client initiates the BOOTP protocol by broadcasting a BOOTP Request packet that indicates the MAC identifier of the client as the source and indicates an IP broadcast address as the destination. Again, this solves the “chicken and egg” problem in a manner similar to RPL so that the client does not initially need to know the address of a boot server, except that the broadcast address used is an IP address, not a MAC identifier. 
When a boot server receives the BOOTP Request packet, it looks for a record with the client's MAC identifier in its table of clients. If the boot server finds a record for that MAC identifier in the table, the boot server sends a BOOTP Response packet to the client that contains the IP address that is assigned to the client and the name of a file containing an initial NBP that is to be requested by the client. This information is maintained in the client's record on the boot server. The BOOTP Response packet also contains the IP address of the boot server.
When the client receives the BOOTP Response packet, the program instructions in the client's ROM saves the client's assigned IP address, the IP address of the boot server, and the name of the initial NBP file. The program instructions in the client's ROM then send a Trivial File Transport Protocol (TFTP) Request packet to the IP address of the boot server that requests the file containing the initial NBP. The boot server responds by sending TFTP Data packet(s) that contain the initial NBP. The initial NBP is written into the client's RAM. Once the initial NBP is received, the client's ROM transfers the client's execution to the initial NBP.
A newer set of IP protocols, collectively called the Preboot Execution Environment (“PXE”) as described by Intel® Corporation in the Preboot Execution Environment (PXE) Specification Version 2.1, has been developed to provide more flexibility than is available with BOOTP. PXE uses a follow-on protocol to BOOTP called the Dynamic Host Configuration Protocol (“DHCP”) that permits much more flexibility and capability in configuring clients (hosts) on the network. This includes the dynamic assignment of IP addresses to clients that may or may not have been pre-listed on the boot server or any other server. PXE also defines other protocols based on extensions permitted in the format of DHCP network messages that can be used to identify the architecture of a remote boot client, to indicate to boot servers that the client is PXE enabled, and to direct the client to the address of a boot server that could be located anywhere in the world. PXE permits each of the following services used to remote boot a client to exist on a separate server machine, permitting greater server configuration flexibility to support client remote boot as well as other client and user support activities simultaneously:                The DHCP service that assigns an IP address to a client.        The Proxy DHCP service that directs the client to a BINL or Boot service.        The Binary Image Negotiation Layer (BINL) or Boot service that directs the client to a boot server operating a TFTP service, and that provides the name of the initial NBP file to request.        The TFTP service that delivers the initial NBP file to the client.        
PXE also defines a set of remote boot support criteria that must be present in the BIOS ROM, option ROM, or option ROM emulation software of the client, including an application program interface (“API”) that permits the initial software loaded into the client's RAM to make requests for additional software and data to permit the remote boot process to complete.
The RPL, BOOTP, or PXE remote boot process described above may do more than load software into the client's RAM, depending on the end-user software environment that is defined for the client. More software may be required than can be placed simultaneously in the client's RAM so that some of it has to be stored on nonvolatile local media (such as a hard disk) so that it can be retrieved when it is needed. It may be desirable for the client to store some, or all, of the end-user software environment to nonvolatile local media (such as a hard disk) so that the client will later have the ability to be booted locally. In such cases, some, or all, of the user software environment is “remote installed” on the client in addition to being remote booted on the client.
An important feature of the RPL, BOOTP, or PXE remote boot process is that the specifications of these processes do not place limits on the function of the initial NBP or any of the other software that is remote booted or remote installed to the target client. This permits that software to perform functions in addition to remote boot or remote install of a previously defined client software environment. One possibility is that such software may be used to discover and scan information about the hardware configuration of the client and report it back to the boot server. The boot server could then use this information to create or update the client software definition so that it matches the hardware configuration of the client before it is transferred to the client.
Present implementations of the remote boot or remote install processes described above require that the client software environment(s) be completely defined prior to the initiation of the remote boot of each client. A number of variations of this are available:                A single default client software environment may be defined for all remote boot clients. This may work if all clients have the same hardware configuration, but may not work as well when there are a variety of such clients connected to the network.        A limited set of alternate default client software environments may be defined. A selection menu is provided to the end-user of the client so that one of the default client software environments may be selected. This provides a limited selection of client software environments that may not reflect entire variety of clients connected to the network. Also, this method requires user intervention to complete the client remote boot process, and the user may not select the appropriate software environment for the client.        The system administrator may define a specific software environment for each client. The administrator must assume or require perfect knowledge of each target client's hardware configuration. This may be quite difficult, particularly for networks that implement PXE where the clients may be widely scattered. Also, this set of specific software environments is difficult to maintain if the set of remote boot clients changes frequently and/or the hardware configurations of individual clients can change frequently.        
These present implementations of the remote boot or remote install processes also make it difficult to implement system-wide policies governing the software environments of clients. For instance, such a policy might be to install Microsoft® Windows NT™ on all machines of a first type (e.g., all IBM® PC 300PL systems with more than 64 MB RAM), Microsoft Windows 2000™on all machines of a second type (e.g., all desktops with more than 128 MB RAM), and Microsoft Windows™ 98 on all machines of a third type (e.g., all laptops). Additionally, it may be difficult to install a large number of machines efficiently without user or administrator intervention. For example, in the above scenario, a system administrator might be reduced to manually defining each target device by MAC address to the management system in order to achieve the described system-wide policy.
It would be desirable therefore to provide a method of remote booting a target client in a network environment that permits the client software environment of each individual client to be created, selected, or updated at client remote boot time based on client discovery and hardware inventory scan that is performed on the client as part of that remote boot process. The results of the client and hardware inventory scan could be reported back to the server, where those results are used as input to the client software environment definition process. This would result in the appropriate client software environment for the client as defined by the client's hardware and/or any system policies governing that hardware. This appropriate client software environment would then be transferred to the client during the remainder of the client remote boot process.